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A major problem In the military wargaming arena is the difficulty 
in understanding and utilizing currently available user interfaces. 
Users span a broad range in terms of rank, background, technical 
skill, perspective, and computer literacy. Military workloads and 
complexity of computer and wargaming systems preclude familiarity 
with system interfaces. New users are inundated with a variety of 
obstacles, including unfamiliar hardware and cryptic command struc- 
tures, as well as widely varying wargaming software systems. In most 
cases, in-depth training is required before a wargaming session can 
commence, thus consuming valuable time, resources, and money. 

This thesis pursues the specific application of the “visual” inter- 
face and windowing to the user interface of wargaming systems for the 
purpose of improving the utility and usability of these systems to their 
users and sponsors. 
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I. INTRODUCTION 



A. PURPOSE OF THESIS 

The purpose of this thesis is to examine the most effective utiliza- 
tion of currently available technology for the enhancement of user 
interfaces for wargaming systems, in particular the Joint Theatre Level 
Simulation (JTLS) and the Battle Group Tactical Trainer (BGTT). The 
JTLS is a theatre-level computer-assisted wargaming system which 
models two-sided air, ground, and naval combat. The JTLS was pro- 
duced for joint military usage. The BGTT is a computer-based large- 
scale simulation of the naval warfare environment and was produced 
for use by the United States Navy. Both systems have far reaching 
utilization by numerous commands and individuals. 

The author, having spent three years as a systems analyst at the 
United States Readiness Command during the development of JTLS, 
recognizes the need for improvements in the ease of use of the JTLS 
system as well as similar large-scale wargaming systems. A level of 
player training of one to two weeks in duration is common before they 
are competent to properly control the execution of a JTLS wargame 
exercise. In other systems, it is common for trained dedicated opera- 
tors to act as assistants to the players and provide the player-machine 
interface. Even though the investment of time and money in those 
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operators is considerable, it seems that the expenditures are justified 
due to a high usage rate of the gaming system. 

Since the design and implementation of the JTLS and BGTT sys- 
tems, the technology available for implementation of more effective 
user interfaces has been successfully implemented and proven in 
general-purpose systems as well as other special-purpose systems. 
This available technology has not been applied in these two actual 
wargaming systems even though it shows promise. Through the use of 
such systems and well-developed user interfaces, the casual user can 
rapidly be imbued with a level of skill such that he can effectively per- 
form within a greatly abbreviated time span. 

One available technology is that of the visual interface. A well- 
known implementation of a visual interface is in the Macintosh micro- 
computer system. The Macintosh system uses icons and a pointing 
device as a means of communication between the computer and the 
user. A large part of the system’s success can be attributed to the 
“Desktop” metaphor, which allows the user’s familiarity with common 
desktop items to be transferred to the control of the computer system 
itself. The extent of visual expression in the Macintosh system is very 
strong. 

Another vital aspect of technology which has developed since the 
design of JTLS and BGTT is that of hardware efficiency. Lowering 
hardware costs coupled with increased capabilities has brought forth a 
new affordable level of graphics utilization in computer systems. 
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A number of current systems developers are exploring the use of 
windowing and window management which, to be implemented effec- 
tively, need these graphics capabilities. Because hardware is more 
reasonably priced and software has reached high levels of sophistica- 
tion, widespread use of windowing and graphics is now feasible. Since 
windowing technology itself shows a great deal of merit and room for 
application in general, this thesis will look at windowing and its possi- 
ble applications in wargaming. 

B. METHODOLOGY 

1. User Interface Research 

The beginning of this study took a very broad perspective of 
the user interface and improvement thereof. It was a preliminary 
assumption that the user interfaces of large-scale wargaming systems 
have a strong need for improvement. Beyond that was the question, 
“How should those improvements be made?” 

A review of user interface literature was undertaken to search 
for answers to this question. As a result of that investigation, it was 
the author’s opinion that much of the literature was inconclusive in 
defining an operating environment where a user’s performance can be 
optimized with a minimum of training. The information available was 
very general and totally void of functional models for practical 
application. 



There exist a number of user interface guideline “checklists” 
which enumerate the many criteria of a “good" user interface. The 
most prominent of these is titled Guidelines for Designing User 
Interface Software, by Sydney L. Smith and Jane N. Mosier. Addition- 
ally, Ben Schneiderman, an expert in the design of user interfaces, has 
authored several books on the subject. 

Unfortunately, systems developers must measure many task- 
specific needs within their application against these checklists only to 
produce a vague and confusing mental model of what they need to 
produce. After this process, there is no guarantee that the interface 
will be effective. It may merely consist of a spaghetti of favored 
attributes. Therefore, such guidelines may be helpful in making spe- 
cific user interface decisions, but a ground-up, full-scale system 
approach presents many perplexing questions. In this respect, the 
literature search proved to be lacking in fully developed models for 
proven and accepted user interfaces. 

The literature did, however, reflect a favorable direction in 
user interface technology which is now gaining wide acceptance. This 
technology could represent a general model for the development of 
user friendly interfaces. It is the graphic-based visual interface tech- 
nology. Basically, the visual interface is the use of “visual expressions," 
a combination of text and graphics used for communication under a 
system of interpretation. The Macintosh is the currently accepted 
“standard” of the visual type of interface. 
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2. Projects. Theses, and Implementations 

In parallel with the user interface research, several masters 
level projects and theses were reviewed. One Naval Postgraduate 
School student, Rob Irving, developed a program where the Macintosh 
acted as a command input terminal to the Naval Warfare Interactive 
Simulation System (NWISS, predecessor to BGTT). His objective was 
to “take advantage of the Macintosh windowing and mouse features 
and incorporate the NWISS command syntax in the software to pro- 
duce a method of rapidly entering error-free commands.” The project 
successfully demonstrated that the concepts of the Macintosh system 
user interface allow “rapid and easy command input for NWISS” with- 
out prior knowledge of the NWISS command syntax (Irving, 1986). 

A thesis produced by Mark J. Sweeney and Kenneth J. Bitar 
(1986) did further research on the question of implementation of user 
friendly input devices to the NWISS. This study favored the use of 
continuous voice input over that of a Macintosh interface “if subject 
training time is not a significant restriction.” Standard keyboard entry 
and continuous voice input were favored for trained participants. The 
results reflect that users of the Macintosh interface had only thirty- 
five minutes training each to practice, as opposed to six hours training 
on the voice system and high “lifetime exposure to keyboard technol- 
ogy.” Additionally, the Macintosh input terminal had the lowest error 
rate under certain conditions. They concluded that, with a minimum 
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of introduction to a speech or Macintosh system, near -equal perfor- 
mance can be attained to that of an experienced typist. 

Recently, in another Naval Postgraduate School thesis, a 
masters student studied the design and development of a prototype 
for a visual interface to the Joint Theatre Level Simulation (JTLS). He 
concluded that “a graphical application of the game is a very efficient 
and desirable method to effect player inputs.” (Lower, 1987) 

Investigation of other research in the area of the user inter- 
face, and particularly the visual interface, led to the Naval Ocean 
Systems Center, San Diego, where the development of a knowledge 
based graphical interface is underway. This system is proposed to be 
the “command center of the future.” It takes advantage of compo- 
nents of the visual interface as well as voice input/output technology 
and shows great promise for allowing the user to interact in a more 
natural and efficient workstation. 

3. Wargame Research 

A portion of research has been directed at the two applica- 
tions, JTLS and BGTT. Research has been conducted through direct 
interaction with the systems, study of the available documentation, 
observation of game playing by organized teams, and interviews with 
sponsors as well as users. The user interfaces have been compared 
and contrasted. The primary criteria for selection of these two sys- 
tems in this study are: 1) they are both major systems, widely used 

and recognized, and 2) they directly contrast in the primary input 
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methodology. The JTLS is basically a menu-driven system while BGTT 
is primarily a direct syntactical command entry system. 

During the development process, sponsors and users are 
often forced to conceptualize “what they want” long before they have 
any idea of what they really need. To further complicate problems, the 
user interface issues may not be addressed due to the overwhelming 
motivation to successfully model realistic simulation of war. It is 
common for interface considerations to take a “back seat” to every- 
thing else with the assumption that they hold less importance and will 
eventually fall into place anyway. 

Common problems observed in the large-scale wargaming 
systems include, but are not limited to: 

1) Navigation problems. Users find themselves lost, not knowing 
where they are within the command structure and not knowing 
what action to take next. 

2) Syntax errors and complex command structure problems. Users 
make repeated errors and need lists of commands with the 
appropriate syntax at their side during play. 

3) Speed problems. The complexity of the systems coupled with 
the simulation speed provide a compounded problem for the 
player who is trying to stay abreast of simulation events. 

4) Developer support. Due to game complexity, developer support 
is often required for long periods of time after delivery for 
imparting understanding of the system and user training. 

5) User interface representation. The systems are very difficult to 
learn and use, and very easy to forget. There is no standardiza- 
tion in the interface. Even with all the variations in existing user 
interfaces none are notably “user friendly.” 
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6) Output overload. Users find themselves searching through 
numerous status reports and other output in attempts to find the 
information they need to continue effective game play. 

C. SCOPE AND DIRECTION 

As discussed earlier, preliminary research shows strong promise 
in development of visual user interfaces in wargaming. While the 
wargaming environment is complex, an enhancement to the user 
interface may provide enhanced usability and thus improved ease and 
frequency of utilization, which will provide increased information 
capabilities and decreased costs. Increased information capabilities 
will be a direct result of increased usage, which will be possible due to 
lower overhead in both time and money. Cost decreases in terms of 
dollars should be derived from lower training and personnel support 
costs. 

From this point, this thesis will present a survey of wargaming, 
including general descriptions of the JTLS and BGTT systems and 
their respective user interfaces. Research will further encompass an 
in-depth analysis of the attributes of a visual interface. The Macintosh 
system will provide a case study of a successful visual interface imple- 
mentation methodology. Then the formulation of a general wargame 
visual interface model will be introduced with specific recommenda- 
tions for the JTLS and BGTT systems. 
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n. MILITARY WARGAMING 



A. THE HISTORY OF WARGAMING 

Wargaming today takes on many forms and functions, but the his- 
tory of wargaming shows that the development of wargames has 
brought the games through various states of favor as well as disfavor by 
assorted groups of users. Before discussing the history of wargaming, 
a definition of wargaming is in order. “A wargame is a simulation, by 
whatever means, of military operations involving two or more opposing 
forces, conducted using rules, data, and procedures designed to 
depict an actual or assumed real life situation.” (DON, 1985, p. 2-1) 

Early war games, during the seventeenth century, were military 
chess or war chess games which had two sides of equal strength, each 
with known dispositions but unknown intentions. These games were 
further developed with the concepts of aggregation and terrain fea- 
tures. One of these games— the King’s Game (developed in 1644 by 
Christopher Weikhmann)— was used extensively as a practical aid to 
military training. Another game, called War Chess, was played on a 
board of 1,666 squares and was used to train military officers of 
Germany, France, Austria, and Italy (Fox, p. 8). 

In 1811, the von Reisswitz game was developed. It was the first 
game to break away from the chessboard environment. Terrain was 
modeled in sand at first. Colored paper attached to blocks was used to 
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represent troops. The king of Prussia sponsored this game, which 
became operational in an improved version with porcelain game 
pieces and plaster terrain (DON, p. 3-1). Czar Nicolas played this 
game in Russia (Fox, p. 9). 

Further modifications of the von Reisswitz game were made by his 
son in 1824, including using a map instead of a sandtable and writing a 
set of improved rules for playing the game. Forces were represented 
by properly proportioned metal pieces and rules were based on realis- 
tic troop movement rates as well as delays in communications. 
Opposing forces were designated red and blue, which is a convention 
still used in most wargames. A designated umpire used dice with 
varying numbers of sides along with number tables to determine out- 
comes and assess battle losses. This game was called the 
“Kriegsspier and gained wide acceptance (Fox, p. 9). 

Kaiser Wilhelm II ordered that the Kriegsspiel be adopted by the 
German Army. In time, the improved Kriegsspiel spread to virtually 
every country with a standing military. Professional groups formed to 
play the Kreigsspiel and clubs sprang up to promote interest in the 
game. Also during this period, Alfred Graf Schlieffen, Chief of the 
German General Staff from 1892 to 1906, used the game extensively 
for experimentation to develop a series of “Schlieffen Plans" for the 
invasion of Belgium and France in World War I (Fox, p. 10). 



18 



After World War I, interest shifted from rigid play to free play of 
the game. This method was characterized by disposal of the strict 
rules in exchange for dependence upon the judgement of the game 
director for game decisions. This was a forerunner for the type of 
political/military game now played by policy makers worldwide. 

Germany continued extensive use of the wargame during the first 
half of the twentieth century. Wargaming flourished under Hitler and 
was credited for the smoothness of at least the initial operations of the 
German invasion of France and Belgium (Fox, p. 11). Unit commander 
knowledge was in large part derived from wargame experience, since 
after 1918 the wargame became an important part of the German offi- 
cer’s training. 

Japan used wargames as educational tools in their war college 
because the successes during the Russo-Japanese War of 1904 were 
directly attributed to wargaming (DON, p. 3-3). The Japanese used 
wargaming extensively prior to World War II. Pearl Harbor and the 
occupation plan for the Pacific were gamed in a session of far-reaching 
scope conducted by Admiral Yamamoto, the Japanese combined fleet 
commander in chief (Fox, p. 12). 

American involvement in wargaming was minor during this 
period. In the early stages, the United States adapted German games 
which were introduced in the army in 1867. The first American work 
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on wargaming was entitled “The American Kriegsspiel" and was pub- 
lished by Major W. R. Livermore in 1879 (DON, p. 3-3). 

Captain Alfred T. Mahan, president of the Naval War College, 
expressed strong interest in a series of lectures on wargaming pre- 
sented by William McCarty Little in 1887. This provided the founda- 
tion on which continued wargaming activity has long been based at the 
Naval War College (DON, p. 3-4). Prior to World War II, wargaming was 
generally confined to the service schools for the purpose of training, 
though the United States Navy is credited with “considerable fore- 
sight’" because of the wargaming activity during World War II (Fox, 

p. 12). 

Since World War II, the introduction of the digital computer has 
dramatically changed the face of wargaming. The capability of high- 
speed computation and simulation techniques have given even greater 
flexibility to the gamers for educational as well as analytical utilization 
of the now numerous available wargames. 

Today, wargaming is used for many applications. Force planning, 
research, development of operation plans, and education and training 
are the primary uses. Education and training is by far the most exten- 
sive use. The service war colleges as well as other military education 
commands have well-developed and extensively used wargaming capa- 
bilities. Other world-wide commands, many of which are operational. 
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use wargames for strategic and operational planning, training, and 
exercise support. 

B. CURRENT SYSTEMS 

As mentioned above, there are numerous wargames available to 
users today. Although manually played wargames are still in use, this 
thesis will address only wargames implemented on digital computers. 
Specifically, the systems to be addressed are two current major 
wargame systems in popular use throughout the Department of 
Defense today, the Joint Theatre Level Simulation (JTLS) and the 
Battle Group Tactical Trainer (BGTT). 

1. The JTLS System 

The Joint Theatre Level Simulation (JTLS) is a computer- 
assisted wargaming system which models two-sided air, ground, and 
naval combat. It can be used for warfare training, joint operational 
planning, and doctrinal analysis. The model is theatre independent 
(CPS, p. 2-1). 

JTLS was developed by the Jet Propulsion Laboratory for a 
consortium originally consisting of the United States Readiness 
Command, the United States Army War College, and the United States 
Army Concepts Analysis Agency. This JTLS system was formed as an 
effort to develop a model general enough to address each agency’s 
fundamental questions and yet rich enough to be useful throughout the 
joint Department of Defense community. The design of JTLS is based 
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on a very extensive, detailed user requirements study and the use of 
computer simulation capabilities. 

The JTLS software is designed to operate on the Digital 
Equipment Corporation VAX 1 1 series minicomputer. Associated with 
the VAX system are various storage media and input/ output devices. 
The minimum input/output hardware configuration consists of four 
video terminals and one on-line printer. In the minimum configura- 
tion, the technical coordinator and controller each have one terminal, 
and each force commander has one terminal. The number of players 
is flexible to meet various gaming and personnel requirements. It is 
desirable to have a graphics display and input pad for each commander 
and the controller. The “standard" game configuration consists of ten 
video terminals, three graphics displays, and three printers. 

2. The BGTT System 

The Battle Group Tactical Trainer (BGTT) is implemented as 
a real-time interactive, discrete event, time step computer simulation 
of the naval warfare environment. The BGTT supports two-sided play 
and an umpire-like control function which handles neutral forces and 
can monitor or participate in scenarios (NOSC, p.1-1). 

The BGTT was developed for use by the United States Navy to 
address the tactical aspects of naval warfare. The BGTT can be used 
for evaluation of new tactics and doctrines, support of major at-sea 
exercise planning and reconstruction, analysis of proposed or 
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postulated fleet requirements, and validation of command control 
requirements (NOSC, p.1-4). 

The BGTT software is partitioned into five major functions 
and is designed to operate on the Digital Equipment Corporation VAX 
11 series minicomputers in conjunction with MEGATEK Corporation 
graphics display systems and various interface devices configured in 
up to a maximum of eight command centers. 

C. THE JTLS AND BGTT SYSTEMS USER INTERFACES 
1. Defining a User Interface 

Stating the definition of a user interface is at the same time 
defining other older, but commonly used terms such as “man-machine 
interface” or “human -computer interface.” Specifically, the user 
interface is the site of interaction between the user and the computer. 
The user generates inputs and the computer generates outputs. 

In conventional systems, the primary method of user input is 
by keyboard while the primary method of output is from a video 
screen. Other systems have brought forth a wide variety of input and 
output devices. The inclusion of hardware devices alone in the defini- 
tion of the user interface, though important, is somewhat incomplete. 

A distinguishing factor in any user interface is the driving 
software of the application involved, which controls the manner and 
methods of interaction. This software decides what control actions 
will be effected and what representations will be displayed to the user. 
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In effect, this portion of the user interface governs the interaction at 
hand. 

The user interface is becoming recognized as a significantly 
more important part of any computer system application because of 
the strong effect of the interface on the effective and efficient utiliza- 
tion of the application. The tremendous expenditure of money and 
resources is of little value if the users lack operating skills, alertness, 
or motivation. 

2. The JTLS User Interface 

The JTLS user interface is provided by one of four funda- 
mental programs called the Model Interface Program (MIP). This 
software provides a continuous interaction between the warfare simu- 
lation model and the players. The Model Interface Program provides 
the following capabilities: 

1) Entering orders. 

2) Processing orders. 

3) Communication between players and controller. 

4) Communication between players and the warfare simulation. 

5) Accessing and using support information. 

6) Saving orders in Order History Files. 

The Model Interface Program is a purely menu-driven inter- 
face with structured command entry and template fill-in (CPS, p. 3-8). 
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Separate graphics software provides graphic representations 
in the user interface on a dedicated graphics display screen. Current 
tactical situations can be displayed in color with graphics which have 
zoom capabilities (to change map scale) as well as iconic and textual 
unit information. Graphic representations are in the form of Defense 
Mapping Agency maps overlaid with text and standard military unit 
symbology. 

User interface hardware in a JTLS workstation consists of a 
Digital Equipment Corporation VT-100 video terminal or a VT-100 
compatible terminal, and a graphics display system comprised of a 
large-screen Sony monitor and a GTCO graphics pad. 

The VT-100 terminal provides command input via a menu 
driven system with templates. Commands may be “stacked” or syn- 
tactically listed instead of following the structured menu interface. 
The terminal screen is divided into three portions. The divisions 
provide a game status line at the top, an output area in the center of 
the screen, and an input area at the bottom. 

The status line provides game security classification, player 
terminal function, game speed, number of messages waiting to be 
read, and game time expressed in date-time group format. The center 
portion of the screen provides game output in the form of messages 
and various game reports. This space is also used to display templates 
which are currently being used to complete command input. The 
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lower portion is for game input. Keystrokes are displayed to this area 
and echoed to the appropriate template area. See Figures 1 and 2 for 
typical JTLS command entry screens (CPS, p. 5-3 and 5-14). 

The graphics pad and monitor allow graphic status of the 
game to be represented to the player on a frequently updated basis. 
Information regarding unit status such as unit strength is depicted 
continuously, while more specific information such as actual lati- 
tude/longitude may be chosen by selection using the graphics device. 

Since JTLS graphics were produced later in the development 
cycle, the addition was an extremely welcome one. Before JTLS 
graphics became available, primary information for game play was 
most often derived from game reports and status displays on the 
VT-100. Depending on the type of information required, this may still 
be the case. 

3. The BGTT User Interface 

The War game mode of BGTT provides the user interface. It 
provides a set of orders which allow the users to control game action 
and progress. Specifically, information display orders and force con- 
trol orders are the commands available to a player during the game. 
These orders are syntactic commands of the following general format: 

key(system output) <data entry>. 
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JTLS COMMAND SELECTION MENU 



— 4 -' 

£ 



if r 
£ C 



- CL 



N 1 

L. J2 



-L — C 

r £ 



> 

> 

Z 

Z 

z 

m 









;; 




: £ 






















£ 


c 


c 


c 












«• 




— 


c 


<— 


— 






c 










: 






, 






z 










: Z 




c 


u 




n 




• • 








: Z 






w 




a 


z 


LJ 




















W 


r. # 


















— • 




— » 




















U 


*— 


















rnm 


z 


u 












•• 






.*•, 


—j 


Lj 










M 


I 


•• 




m- 


uL 


CL 








•• 




h- 


z 




K 






• 






u 


H- 


M 


y— 




<x 






U 




z 




3 


«— 




n 


Q 




L 


0 




<— 1 


z 




Z 




3 


LJ 


— » 


Z 




\- 




1- 








<—» 


K 


Ui •• 






JL 


u 


z 




•• 


Ll 


C 


lT LL 


• - 


• h- 


u 


LU 


Ui 




Ui 


<— i 




Ll 


l 3 


h 


X 


c 


h- 


Lu 




u 


in 




u 


C 


- <x 


K C 


a: 




z 


cn 




Uj iT 


Z H- 


t- 


CL 


u 




H UJ 


<i 


u 


CL 3 


~ 


) X 


c 


Ql 


in 




C IT 


-j 


<r 


















UJ 


u 


H 




• • 




• • 


• 


• 


« 


CL 


GC ll 


z 


h- 


— (N 


n 


yi 


o 






U UJ 


3 


<t 
















r 


* cr 



cs 



28 



JTLS Template 



“Key” is equal to the key words of the order. System output refers to 
the parenthetical expressions output by the system to explain or 
prompt for the next item of data to be supplied by the user. Data entry 
refers to expressions appearing within the <> symbols denoting the 
required user entered data. For example, an order in BGTT may 
appear as follows: 

DEFINE CHAFF (life of) <minutes> (width) cnautical miles> (depth) 
<feet>. 

Use of keyboard entry allows order key words to be entered in abbre- 
viated form if a unique portion of the command is entered. 

An alternate method of command entry is available to 
BGTT players. A menu display is available to help the user sequence 
the fields within the order and also sequence the various orders 
through the use of color on the display. The orders are displayed on 
the geotactical color display console. As an aid to the user, the orders 
are displayed in a menu format, showing the correct syntax and 
allowable options with system-generated prompting to assure proper 
order entry. This function is provided through combined use of the 
graphics display and tablet with a puck selecting device or optional 
joystick. 

The user interface hardware in BGTT consists of a number of 
possible items, but a standard command center configuration will have 
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one operator input/output terminal with a keyboard, a color graphic 
geographical and tactical display, several black and white monitors to 
display automatic status boards (usually four are used), a graphics 
tablet, and an intercom for communication. Other options include a 
joystick, a large screen display, a printer/plotter, and a voice 
synthesizer. See Figures 3 and 4 (NOSC, p. 1-1-3) . 

The BGTT interface is elaborate in the provision of multiple 
frequently updated terminal screens. Four text-based automatic status 
board screens as well as one graphics screen are continuously available 
for player reference. The overall effect of this interface along with the 
integrated voice communication system is the achievement of 
relatively lifelike command center environment. 

4. User Interface Problems 

In spite of concerted efforts by developers and sponsors to 
provide clear, reasonably easy-to-use interfaces, wargames today are 
lacking in the necessary components for meeting the needs of a fast- 
moving modern military environment. A major source of cost in the 
military wargaming arena is training users to a level of proficiency 
where the systems can be utilized efficiently. There is often consider- 
able difficulty in understanding and utilizing currently available user 
interfaces. 

Users span a broad range in terms of rank, background, tech- 
nical skill, perspective, and computer literacy. Military workloads and 
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Typical BGTT Command Center 
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Typical BGTT ASTAB Display 



complexity of computer and wargaming systems preclude familiarity 
with system interfaces. New users are inundated with a variety of 
obstacles including unfamiliar hardware and cryptic command struc- 
tures, as well as widely varying wargaming software systems. In most 
cases, in-depth training is required before a wargaming session can 
commence, thus consuming valuable time, resources, and money. 

The primary goal in a wargame used for the purpose of train- 
ing and education is to develop and refine warfare skills. Unfortu- 
nately, the above-mentioned complexities of the systems and the 
widely varied skill levels of the users create difficult circumstances 
which must be overcome before reaping intended benefits. A large 
portion of available training time is often spent teaching the user to 
interface with the system. 

In other cases, where the wargame is used for planning or 
analysis, players are subject to extended hours of play as well as 
repeated play. Typing input in syntactically correct phrases, which is 
in itself difficult enough, becomes increasingly difficult with fatigue. 
Although the players involved may play a particular game on a regular 
basis and may become very familiar with the interface, if interest is 
lost and fatigue causes errors, the resulting analyses may be invalid. 
Additionally, familiarity with one or two interfaces does not guarantee 
any transfer of understanding since there is very little consistency or 
standardization in the available interfaces. 
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In addition, the military personnel system creates frequent 
personnel turnovers, which in turn dictates that experienced person- 
nel are frequently replaced by inexperienced personnel. It is not 
uncommon for thorough training of an inexperienced user on a com- 
plex wargaming system to take months or in some cases years before 
required job proficiency is attained. 

General problems of cryptic command structures, inconsis- 
tent interfaces, computer system hardware and software complexities, 
as well as the intricacies of the wargames themselves create a myriad 
of problems for training commands and sponsor commands. 

Specific problems are numerous. It has been observed that 
players cannot learn commands and therefore cannot play without 
notes and manuals at their sides. Even with these memory aids, play- 
ers still find their input commands have syntax errors and their input 
parameters are often far from reality and/or the sponsor’s intentions. 

Another problem is information overload. As players partici- 
pate in the game, automatic reports are generated on screen and on 
paper, inundating the user with a lot of unusable information due to 
the fact that he cannot find what he needs. The user has little or no 
control over the information and the presentation of that information. 

This brings us to the problem of control. The wargame player 
is controlled by the system in a sort of maze-like race. The player is 
continually trying to keep up with the game action while trying to 
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figure out how to use the system and interface, not to mention his 
efforts to grasp the relevant portions of the database he is supposed to 
be using, all at the same time. 

Even structured menu and template input causes trouble 
because users become “lost” in the command structure or menu tree. 
Navigation problems are a major difficulty in these systems for the 
unfamiliar user. Additionally, there is often no escape from inadver- 
tent choices or mistakes. It is not uncommon for a player to find 
himself in the lower level of a menu tree to realize that he is not 
where he wants to be. He then may request help, follow the advice, if 
available and clear, then try to figure out how to accomplish what he 
originally intended to do. 

Such problems are compounded by lack of experience with 
hardware, computers, and/or wargame simulation models in general. 
Often users do not know how to perform simple tasks on the com- 
puter and keyboard such as the use of function keys or interpretation 
of user messages on the screen. Often, users require not only 
wargame training, but fundamental computer skill training. 

The purpose of this thesis is to take wargame system inter- 
face problems and examine an alternative method of user interface. 
No efforts in the area of standardization have been approached in the 
currently available wargame user interfaces. In the following chapter, 
this thesis will examine the Macintosh interface standard produced by 
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Apple Computer, Inc. with the following research question, “Can this 
technology be effectively applied to the solution of problems in the 
user interfaces of systems such as JTLS and BGTT?” 
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m. CURRENT USER INTERFACE TECHNOLOGY 



A. A USER-FRIENDLY INTERFACE 

1. The Macintosh-like User Interface 

The Macintosh microcomputer system represents a new 
standard in the microcomputer industry. As described later, the 
Macintosh has a number of characteristics which differentiate it from 
other systems. There are many reports of very positive reactions 
regarding the use of this system. Some of these reactions include 
feelings of: 

1. Control of the system. 

2. Competence in task performance. 

3. Intuitive ease in learning the system. 

4. Ease in assimilating advanced features. 

5. Confidence in retention of skills. 

6. Enjoyment in using the system (Schneiderman, p.180). 

Based on research done by Xerox corporation, the Macintosh 
user interface is very different from traditional approaches. It is the 
result of several years of intensive research on how people interact 
with computers and how the interface should be designed to be both 
highly productive and painless for its users. (Simpson, 1986, p. 2) 
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The vision was to bring the power and versatility of com- 
puters to ordinary people (Apple Computer, 1986, foreword p. ix). 
Although the concepts created by Apple were initially introduced in 
the Lisa microcomputer system, the Macintosh represents the most 
mature and successful implementation of those efforts. An interesting 
result of the Macintosh has been that it allows both computer experts 
and novices to share and appreciate the technology. 

The Apple Macintosh user interface was designed to enhance 
the effectiveness of the people using the system. This approach is 
generally called user friendly, although Apple calls it user centered. 
And while the interface is often called simple, Apple maintains that the 
terms direct and effective make more sense (Apple Computer, 1986, 

p. 2). 

The Macintosh user interface is called the Apple Desktop 
Interface or, to the indoctrinated Macintosh user, the Desktop. The 
principle on which the Desktop is based is that of a metaphor for an 
actual working space on one’s desk. It is a concrete metaphor with 
which we are all familiar in our daily lives. This metaphorical founda- 
tion, and the way it is represented to and manipulated by the user, 
accounts for the tremendous success of this system. It is presented in 
common terms, which makes it more easily understandable, and it is 
comfortable. 
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a. Hardware Elements of the Macintosh User Interface 



The Macintosh system uses a mouse and keyboard for 
input, and a printer and a high-resolution, bit-mapped screen for 
output. The high resolution graphics screen is a key feature of the 
Macintosh. The black and white screen consists of 175,104 (512 
horizontal x 342 vertical) pixels. This allows applications to be pre- 
sented to users in effective combinations of text and graphics. The 
use of graphic objects for commands, parameters, and features is 
promoted strongly in the Macintosh user interface. The high resolu- 
tion capability of the video screen supports this goal. 

The Macintosh has a highly visual interface which 
requires not only the standard use of a keyboard for entry but also a 
mouse. A mouse is a pointing device which allows users to select 
desired actions by pointing to an object on the screen and clicking a 
button on top of the mouse. 

The mouse, keyboard, high-resolution monitor, and 
printer are common elements in microcomputing today. What makes 
the Macintosh unique is its software. The software, including ROM 
routines, is the basis for the special user-computer dialog. 

A user-computer dialog is a two-way conversation 
between the user and the computer. The user is presented with pos- 
sible choices on the video screen and, instead of making the tradi- 
tional direct command entry or menu selection by keyboard, the 
Macintosh user will most likely point to a graphically depicted object 
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and click the mouse to select it. A large percentage of operations 
completed by the user will generally involve such selection of graphic 
representations with the mouse. 

b. Software Elements of the Macintosh User Interface 

The Macintosh operating system and Finder software are 
universal across Macintosh applications. They provide the basis for 
interaction and control. The operating system provides essential 
functions such as interrupt handling, memory management, and 
input/output to keep the Macintosh functioning (Apple Computer, 
1983, p. 3). With the Finder software, the user can manipulate files 
and start up applications. In normal operation, it is automatically the 
first program to be run when the Macintosh is turned on (Chemicoff, 
1985, p. 591). 

There are a number of visual components in the Macin- 
tosh interface which are used for such tasks as file manipulation and 
program interaction. These visual components, as mentioned above, 
are icons, windows, dialog and alert boxes, pull-down menus, and 
other symbolic control devices. These representations are imple- 
mented in software application programs by calls to the ROM, which 
provides them as standardized functions. Most of these functions are 
graphic in nature. 

As one may note, the Macintosh system is composed of a 
complex foundation of interface software. This interface software may 
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be accessed through the Macintosh 128-kilobyte ROM and is called 
the User Interface Toolbox. Application programmers may therefore 
call from their programs the standard routines which provide the 
broad range of facilities and features of the Macintosh interface. 

The system, while somewhat difficult to learn to pro- 
gram, can present a very friendly interface to its user. The most 
important, and possibly the most difficult, part of programming the 
Macintosh, however, is to put the Macintosh design philosophy into 
effect. It is quite possible to develop an application which integrates 
the excellent features of the Macintosh User Interface Toolbox, yet 
very poorly presents an effective user interface. Therefore, great care 
must be taken in using such a system. There is no panacea, but there 
are helpful guidelines available to the developer. 

2. Lessons Learned From This System 

Due to the recognition that even the best tools if not properly 
used are of little or no value, Apple Computer has developed two very 
helpful sets of principles for the developer of Macintosh applications. 
These principles are based on extensive research which should prove 
useful in programming most any visual interface. The first set of prin- 
ciples relates to general design principles. The second set relates to 
the principles of graphic communication. 

a. General Design Principles 

1) Metaphors from the real world. “Use concrete metaphors and 
make them plain, so that users have a set of expectations to 
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apply to computer environments.” (Apple Computer, 1986, p. 3) 
Audio and visual effects that support the metaphor should be 
used whenever possible. This is based on the fact that most 
users are not experts but people do have direct experience in 
their immediate world. Therefore, using familiar concepts 
makes users feel comfortable. 

2) Direct manipulation. This should be used to give the user a 
sense of control over the activities of the computer. Direct 
manipulation is based on the fact that people expect physical 
actions to result in some sort of physical feedback. Therefore, 
moving the mouse results in a corresponding move of the 
pointer or cursor, and clicking the close box of a document 
causes it to shrink into an icon representing the document. 

3) See-and-point. Users should be allowed to select actions from 
alternatives presented on the screen. This allows users to see- 
and-point (as opposed to remember-and-type). Recognition, not 
recall, is important here; the user should not have to remember 
anything the computer already knows. It is simple for most 
programmers and expert users to work with a command -line 
interface that requires memorization and Boolean logic. This is 
not a simple task for the average user. Through the use of a 
visual and spatial environment, people are able to work effec- 
tively while using the computer in a sensible human 
environment. 

This removes the burden of learning and remembering cryp- 
tic or complex command structures, thus allowing the user’s 
focus to be on the actual task. Recognition rather than recall is 
all that is needed for successful operation. 

4) Consistency. “Effective applications are both consistent within 
themselves and consistent with one another.” (Apple Computer, 
1986, p. 6) The very important reason for this point is that of 
skill transfer. If a user is accustomed to the interface of one 
application and that application is consistent with others in 
operational concepts and elements, then the skills used may be 
transferred to other applications. 

5) WYSIWYG (what you see is what you get). “There should be no 
secrets from the user, no abstract commands that only promise 
future results. There should be no significant difference 
between what the user sees on the screen and what eventually 
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gets printed.” (Apple Computer, 1986, p. 7) This concept 
means that user actions result in feedback which corresponds 
with actions taken. An action to copy a file to another disk dis- 
plays the copy in both places, the original and the new, thus 
assuring the user that the action resulted in the desired effect. 
Also, a document will be printed as displayed on the screen. 
The user does not have to guess or perform uncomfortable 
manipulations to achieve the desired output. This is in direct 
support of the direct manipulation concept. 

6) User-initiated actions. All man-machine interaction should be 
driven by the user, not the system. The user is no longer in a 
reactive state to a machine. A user may receive warnings if he is 
about to take a risk, but the user still maintains control and is 
allowed to make his choice of action, not the computer’s. 

7) Forgiveness. Even the most proficient user makes mistakes. 
The system should be forgiving when mistakes occur. Since 
provided documentation is often avoided by users and since this 
avoidance takes on a form of exploration, users should be 
allowed to learn by doing. In support of this, naive or inattentive 
users should be warned before making unrecoverable mistakes. 

8) Feedback and dialog. The user should be kept informed. Feed- 
back should be immediate and clear. “User activities should be 
simple at any moment, though they may be complex taken 
together.” (Apple Computer, 1986, p. 8) The user must remain 
informed to maintain his state of control over the environment. 
Also, the user needs to be aware of the progress of operations 
and be presented with brief, direct explanations if operations 
cannot be completed. 

9) Perceived stability. “Users feel comfortable in a computer envi- 
ronment that remains understandable and familiar rather than 
changes randomly.” (Apple Computer, 1986, p. 9) The inter- 
face provides a two-dimensional visual stability and a conceptual 
sense of stability with a clear finite set of objects and actions 
within the fast and versatile computer environment. 

10) Aesthetic integrity. “Visually confusing or unattractive displays 
detract from the effectiveness of human-computer interactions. 
Different ‘things’ look different on the screen. Users should be 
able to control the superficial appearance of their computer 
workplaces— to display their own style and individuality.” (Apple 
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Computer, 1986, p. 10) The visual appearance of the screen and 
its components is essential to the Macintosh interface. Apple 
states that “Consistent visual communication is very powerful in 
delivering complex messages and opportunities simply, subtly, 
and directly.” (Apple Computer, 1986, p.10) 

b. Principles of Graphic Communication 

Apple Computer has further guidelines which address 
the graphic aspects of the interface. “Graphics are not merely cos- 
metic. When they are clear and consistent, they contribute greatly to 
ease of learning, communication, and understanding. The success of 
graphic design is measured in terms of the user’s satisfaction and suc- 
cess in understanding the interface.” (Apple Computer, 1986, p. 11) 

Further, Apple has three primary measures for effective 
graphic presentation: visual consistency, simplicity, and clarity. 

These support the concept of conveying real world metaphors in a 
context which will be most appropriate to the application and com- 
fortable for the user (Apple Computer, 1986, pp. 11-12). 

B. THE VISUAL INTERFACE 
1. Using Visual Concepts 

The Macintosh system is certainly not the only system which 
has taken advantage of a visual interface. The Macintosh’s direct pre- 
decessor was the Lisa microcomputer system by Apple Computer. The 
Lisa system heavily influenced a number of products, including 
“Microsoft Windows,” “GEM” by Digital Research, and IBM’s 
“TopView." 
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The Lisa system began to take shape after the Apple senior 
staff visited Xerox’s Palo Alto Research Center in 1980 to see a 
demonstration of Smalltalk. At the end of a three-year development 
period, the Lisa was introduced as the first multitasking windowing 
system for a personal computer. The Lisa did not prove to be suc- 
cessful in sales, but much of the technology was passed to the higher- 
performance, lower-cost Macintosh. Many of the user interface 
concepts used in the Macintosh were in fact developed for use in the 
Lisa (Tesler, 1985, pp. 17-22). 

The Xerox Star system is a widely known system which is 
credited as a forerunner in the implementation of a visual interface. 
Announced in 1981, Star’s use of icons, pointing devices, and an office 
metaphor predate the Lisa and Macintosh. The system had strong 
limitations in that the system addressed the visual interface only at a 
very simple level. To perform in an application environment, Star was 
used in a command mode much like other types of systems (Shu, 
1986, p. 21). 

The significance of the aggregate work discussed above is that 
it brought forth a new standard of user interface which can be called 
the visual interface. A visual interface uses visual objects as the basis of 
communication. “A visual communication object is some combination 
of text and graphics used for communication under a system of inter- 
pretation, or visual language.” The benefit of visual communication is 
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“When humans are faced with cognitive complexity, they often need 
graphics as well as text to help them deal with that complexity.” 
(Lakin, 1986, p. 36) 

If appropriately applied, the visual interface is capable of 
bringing positive benefits in dealing with complex problems such as 
military wargaming. The benefits are even more noticeable when the 
visual interface is contrasted with the user interfaces of the past. 

The typically used menu and command structure interfaces 
are plagued with problems in the areas of syntax, modes, and naviga- 
tion. The visual interface easily overcomes these problems in an envi- 
ronment centered on the user’s control of the system. Learning time 
for new users is greatly reduced because the visual interface is based 
on familiar and intuitive processes and actions. 

Given the particular needs and goals of a given application, 
prototypes of the visual interface can be easily implemented and 
tested for maximum effectiveness. 

2. The Design of a Visual Interface 

Ben Shneiderman (1986), developed a model called “direct 
manipulation.” This model addresses the visual interface and consists 
of three parts: 

1. “Continuous representation of the objects and actions of 
interest.” 

2. “Physical actions or labeled button presses instead of complex 
syntax.” 
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3. “Rapid incremental reversible operations whose impact on the 
object of interest is immediately visible.” 

While the Macintosh system provides an example of a visual 
system, no specific design models have been formulated for guidance 
in development of other specific applications of visual systems. Most 
research supports the principles which Apple developed as user 
interface guidelines, but some recommendations should be empha- 
sized before undertaking the development of a visual interface. 

It is clear that a visual interface in and of itself does not merit 
reward. It is the careful and planned design and implementation of 
the visual interface through which its many rewards may be reaped. 
Application goals must be carefully integrated with the user needs and 
the principles of good visual interface design. This is a primary 
requirement and it is recommended that strong consideration be 
given to the ideals of this approach before development begins. 

As mentioned earlier, the visual interface can be easily proto- 
typed and tested for effectiveness within the context of any appli- 
cation. This aspect requires considerable graphic creativity and 
expertise. Poorly designed graphic tools can produce only poor 
results within the application. Careful, application-specific design 
considerations must be created to communicate with the user clearly 
and concisely. 

Icon, window, menu, and dialog design must be integrated 
into more than a “package” that works together. It should represent a 
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metaphor of reality which will effectively bring the abstract actions of 
the computer into concrete, realistic terms for the user. 

After the initial graphic-based design takes form, a consider- 
able task still remains. Follow-on prototyping and thorough testing of 
the design are critical to success. Prototyping tools exist which allow 
relatively simple implementation of screen, window, dialog, and icon 
design. User interactions and reactions may be prototyped and tested 
through these tools as well. 

The prototyping and testing phase is the most important 
aspect of the user interface design process. The best plans can fall 
when presented to the user who can not or will not effectively use the 
interface. The prototyping methodology is highly efficient in devel- 
opment of the visual interface because it allows low cost and high 
speed at the same time. This is necessary and most productive in this 
type of situation. 

The visual interface design presents special problems of its 
own. Since screen space is limited, the effective use of window 
management is necessary. The following section presents some 
important considerations in windowing methodology. 

C. WINDOWING 

There are associated concepts which are of importance in the 
design and implementation of windows. 
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1. Window Management Design 

Windows provide views for the user into applications. As 
previously discussed, windows may occur in various sizes, shapes, and 
forms. Windows are actually complex graphic representations which 
require highly efficient software structures for their display and con- 
trol. The mechanism which usually provides this service is a Window 
Management System. 

The Workshop on Window Management defines the following: 
“A Window Management System (WMS) is a system service that pro- 
vides for the creation, deletion, and modification of windows. The 
WMS allocates scarce resources (represented by on-screen real estate, 
entries in a colour map, use of mouse and keyboard input devices) 
among contending applications.” (Hopgood, et al, 1986, p. 145-147) 
Functions of a WMS as defined by the same research group include: 

1 ) creating and destroying windows; 

2) redrawing images in windows; 

3) providing titles for windows; 

4) requesting the allocation of color table entries; 

5) requesting sampling input from the mouse, keyboard, or other 
entry device. 

Window design is concerned with a number of aspects, from 
technical to functional, to aesthetic. Assuming that technical capabili- 
ties exist to perform the desired operations at acceptable speeds, 
attention turns to the user oriented issues of function and aesthetics. 



49 



The Application Interface Task Group of the Workshop on Window 
Management defined eight principles to be considered in window 
manager design: 

1) Symmetry— application and window manager should be able to 
do the same functions. 

2 ) Synchrony— single thread of control should exist. 

3) Hints— impossible tasks initiated by applications should be 
allowed graceful exit by the WMS. 

4) Redraw requests— requests should be hidden and redraw mech- 
anism should be simple. 

5) Procedural interface— interfaces should be procedural as 
opposed to exposed data structures. 

6) High level libraries— applications should talk through a window 
manager toolkit. 

7 ) Strategy specification— it should be possible to specify strategies 
such as font or color matching. 

8) Generality— this principle is difficult to achieve. The research 
group expects compromise in this area (Hopgood, et al, 1986, 
pp. 213-214). 

Window management design addresses a large number of 
control issues regarding the participation level of the WMS. The con- 
sensus among the Workshop on Window Management is that most of 
these specific issues should be dealt with at the application level in 
consideration of the application goals. The group also addressed a 
number of important general issues which should be resolved in the 
future to establish accurate conclusions regarding future development 
decisions (Hopgood, 1986, p. 172). 
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2. Window Management Implementation 

Implementation of a Window Management System requires 
the observed workings of the system by the user. Creativity could 
result in innumerable variations across a range of applications, but 
guidelines can be helpful in the general development process. Warren 
Teitelman created a set of guidelines for development of an environ- 
ment where the user is expected to be in control of the system. He 
suggests that the interface should: 

1) Be intuitive— use images suggestive of operations being 
performed. 

2) Accommodate novices and experts— to enhance growth and 
flexibility from ease of use to power. 

3) Allow customization— allow macro mechanisms for expert 
customization. 

4) Provide extensibility— use of macros to extend functionality. 

5) Use lots of feedback— inform, but avoid intrusive interaction by 
appropriate use of feedback. 

6) Be predictable— use a consistent, uniform, easily remembered 
set of basic actions. 

7) Be deterministic— predictable methods are preferred. 

8) Avoid modes— avoid states that persist. 

9) Don’t preempt the user— do not force the user to respond 
(Hopgood, et al, 1986, pp. 187-188). 

The working group agreed that, in the context of the end 
user, a WMS should consider the user’s model to define standards for 
interfaces. Additionally, the group agreed that present methods of 
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representation are unsatisfactory, and that there is presently no obvi- 
ous means of standardization of the user interface. Again, further 
research is suggested. In this case, the group suggested study of 
existing window manager models and better ways of representing user 
models (Hopgood, et al, 1986, pp. 189-190). 

Valuable suggestions were offered by the group on window 
implementation. The window functions should be provided by a 
toolkit approach. This is consistent with the Apple approach to win- 
dow implementation through the Toolbox and Window Manager soft- 
ware. The window manager should provide generic functions which 
can be interpreted by applications. This again is consistent with the 
Apple implementation, which provides generic cut-and-paste func- 
tions as well as others. A final recommendation is that “User Interface 
Management Systems should be developed which enable the rapid 
tailoring of window managers to application requirements. " These 
systems are used to generate window managers. (Hopgood. et al, 
1986, p. 190-191) 

Since windowing is a critical aspect of the visual interface, 
strong consideration and support should be given to WMS develop- 
ment in the context of specific applications by sponsors and develop- 
ers. The success or failure of a visual interface implementation may be 
rooted in the WMS and adequate resources should therefore be 
allocated. 
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The visual interface of today is dependent on windowing, 
although future implementations may explore utilization of spatial 
information, where information is nested in spatial images. These 
images may be thought of as something like projections of information 
allowing a user to “zoom in and out” of an image to obtain more or less 
information regarding that item. This concept is used by the Dataland 
system developed at the Massachusetts Institute of Technology (Bolt, 
1984, p. 24). Research in this area is very young but may show even 
greater promise than the visual interface we commonly know today. 

The visual interface is effective in its current state but, as just 
noted above, there may be any number of improvements and refine- 
ments which may be developed in the future. On the other hand, 
improvement may take the form of an integration of currently available 
technology. 
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IV. A FRAMEWORK FOR USER INTERFACE DESIGN 



A. A GENERIC ARCHITECTURE 

The Decision Support System literature proposes a generic archi- 
tecture to construct a user interface (Bui, 1987). This architecture 
consists of three independent, inter-related modules: 1) the dialog 

unit, 2) the control unit, and 3) the inter-module linkage unit. Various 
user interface representations may be developed within this generic 
model. 

The purpose of the dialog unit is to provide the input/output links 
or physical interface between the user and the system. The software 
portion of the dialog unit contains routines which monitor the hard- 
ware. The hardware portion of the dialog unit may include a CRT, 
keyboard, mouse, touchscreen, printer, or other varieties of 
input/ output devices. 

The control unit guarantees smooth, error-free interaction 
between the user and the system. The checking of syntax and logic as 
well as provision of a help facility is the responsibility of this module. 
Correct and relevant representation to the user is the primary goal of 
this very important unit. 

The inter- module linkage unit provides a liaison of the model with 
the data components or other elements of the system. 



54 



The overall goal of this framework is to provide an effective and 
efficient user interface design strategy focused on learning, creativity, 
and interaction delivered in a friendly, helpful fashion, 

B. A SURVEY OF USER INTERFACE REQUIREMENTS 

A group of forty graduate students from the Information Science 
Department at the Naval Postgraduate School participated in a survey 
regarding the design of a wargaming user interface. Students were 
asked to address each of the three aspects of the above model with a 
description of what they considered important components of an 
effective wargaming interface. All of the requirements they developed 
were with respect to the above framework. 

Students participating in the study were professional military offi- 
cers, familiar with warfare in general but unfamiliar, in most cases, 
with wargaming systems. This data, therefore, provides information 
based on a relatively strong understanding of the user interface, with 
limited exposure to the direct application of wargaming. It should be 
noted, however, that, as professional military officers, the survey par- 
ticipants' training and job experience lend an understanding to the 
strong importance of the content and purpose of wargaming within 
the military. 

The surveys were reviewed and analyzed by compiling a list of fea- 
tures recommended by the survey participants for each of the three 
components within the user interface framework discussed in the 
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previous section. Corresponding recommendations were then tallied 
and ranked in descending order of frequency. 

The dialog unit brought forth the most varied and interesting con- 
clusions in the survey. Survey participants, in their independent 
designs of a dialog component for a wargaming user interface, consid- 
ered several items to be very important. Eighty-three percent of the 
participants recommended a high-resolution graphics monitor as the 
primary output device in the system. Most participants felt that a 
menu-based system was preferable to a command-driven system, and 
in many cases, the participants felt that a menu system should be sup- 
plemented with some other methodology such as windowing (thirty- 
eight percent), voice input/output (thirty-eight percent), icons 
(twenty percent), and/or graphic manipulation (thirteen percent). 

Sixty-three percent felt that a mouse input device was preferred 
to other input devices such as touchscreens, joysticks, or light-pens. 
Sixty percent of the participants recommended a standard keyboard, 
in conjunction with the mouse or alone, although only a very small 
number (five percent) of the participants considered using the key- 
board alone. 

While twenty percent of the participants included high-speed 
workstations in their description, seventy percent neglected to men- 
tion color as an important characteristic of the high-resolution 
graphics monitor/workstation concept. The criteria most often 
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mentioned as important to the user were response speed and ease of 
use. 

The control unit portion of the survey found that the participants 
most highly valued an on-line help facility. In fact, this item, with a 
seventy-percent frequency, had the strongest support of all items 
considered in the survey. Very close to the on-line help feature was a 
rigid input/output error-checking/verification system (ranking sixty- 
three percent), which the participants felt was necessary in any appli- 
cation supporting a wide variety of users. 

Items mentioned with respect to the control unit were all soft- 
ware related except for one item. This was a separate or front-end 
processor to provide high-speed and responsiveness to the user. 
Thirty percent of the participants considered this necessary to pro- 
vide adequate control. 

The remaining recommendations for the control unit were to 
provide simple and clear prompts and messages (twenty-eight per- 
cent), timely and informative feedback (twenty percent), forgiveness 
in error recovery (fifteen percent), and an on-line tutorial (fifteen 
percent). 

In the inter-module linkage unit , the most desirable characteristic 
was modular implementation (thirty-eight percent) for the purposes of 
flexibility and maintenance. Ranking second in this category, with 
twenty-eight percent each, were rapid access via a local central 
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processing unit or high-speed memory and ease of data access and 
availability. 

The participants had a variety of responses but, in general, the 
above provides a condensed overview of the most desirable character- 
istics as seen by prospective users of wargaming systems. The 
developer of a wargaming user interface could consider these char- 
acteristics as a basis for a simplified, generic, user requirements 
definition on which refinements and further recommendations could 
be based. 

C. A FEASIBILITY ANALYSIS OF DESIRABLE WARGAMING 

CHARACTERISTICS 

In the previous section, different characteristics were recom- 
mended by the potential users surveyed. As is typical in most user 
surveys, there is a broad base from which developers and sponsors 
must make limited selections. The determination of good, productive, 
cost-effective characteristics must remain in the final analysis of any 
successful project. Many, although not all, of these decisions are based 
on a union of user and application requirements. Other factors influ- 
encing such decisions may be based on time, hardware, financial, or 
political constraints. 

This portion will address a general set of requirements drawn 
from the broad set of user requirements listed above. Additionally, it 
should be noted that the items mentioned here are discussed in a 
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generic wargaming context as an attempt to provide a general feasibil- 
ity framework and foundation for application-specific issues. 

1. The Dialog Unit 

Within the dialog unit, one must assume varying degrees of 
computer literacy. Use of a wargaming system should primarily pro- 
vide for the development of warfare skills as opposed to computer 
skills. This implies that a high level of sophistication must exist in the 
user interface to remove the user from the problems associated with 
conventional computer interfaces. As recommended by the survey 
participants, a highly graphic-based system can help provide the level 
of sophistication desired. 

Objects familiar to a military officer may be graphically 
depicted so that a minimum of textual information must be read and 
interpreted. This is in support of the time constraints faced during 
the play of a real-time or accelerated wargame. It would be ideal to 
provide the fastest interface possible. High resolution in the graphics 
screen allows detailed and clear representation and hence interpreta- 
tion. This is why a number of survey participants recommended this 
option. It is not only desirable but rather a necessity within the realm 
of current technology. 

To effectively use this graphic technology, the user input 
hardware technology should be at least as sophisticated as the output 
device to remove the user from interfacing with conventional 
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input/output devices such as keyboards. This hardware should consist 
of some type of pointing/picking device. As suggested in the survey, 
user familiarity with and acceptance of the mouse is fairly broad today. 
This lends the mouse a bit of an advantage, although other technolo- 
gies have certain merits. 

In particular, touchscreens require no peripheral device, no 
tracking area on the desktop, and are readily available to the player. 
In the same context, though, touch screens and other devices may 
pose problems of their own. The touchscreen is at times difficult to 
implement and “fine tune" for detailed work such as pixel manipula- 
tion because of finger sizes and screen divisions. No single device is 
perfect, but the mouse is a strong candidate if it can be effectively 
integrated into the needs of the specific application. 

Thirty-eight percent of the participants suggested that voice 
input/output is the ideal medium for use in wargaming. This may be 
the fastest method available if implemented under “ideal" circum- 
stances of very high levels of sophistication. This technology is still 
young and will continue developing into more reliable and promising 
implementations. Voice technology shows much promise and should 
be considered for further research within the wargaming application. 

With the recommendation of high-resolution graphics capa- 
bilities and improved hardware, software implementations should 
address the utilization of detailed screen graphic manipulation. The 
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possibilities include, as suggested by the survey, windows, menus, and 
icons within an environment of graphic manipulation where the user 
can perform tasks by operations on, or with, the graphic objects. 



These elements, coupled with the processing capability to 
provide the power and speed demanded by such graphic manipulation, 
provide a foundation environment on which to build application spe- 
cific implementations of the dialog unit within a wargaming system. 

2. The Control Unit 

Since the control unit must provide for error-free operation, 
the hardware and software must be proven robust enough to handle all 
potential error situations and provide on-line help, automatic feed- 
back, and forgiving continuation of the wargame process. Extensive 
testing and evaluation of any control unit is a necessity, but in a 
wargaming system, with numerous data elements and parameters 
which need to be verified throughout the game, a dedicated processor 
is recommended to reduce the processing burden on the other system 
components. 

Survey participants felt that the on-line help facility was the 
most important part of the control unit. While it is terribly important, 
at least as much effort should be spent in making the control unit 
informative to the player by providing unsolicited guidance during 
game play. All players make mistakes, even the experts. It is usually 
the novice who may not know how to recover. The system should 
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allow flexibility here to give the expert an alert of a problem without 
the drudgery of details, but also give the novice the option of specific 
guidance out of the problem area. 

3. The Inter-Module Linkage Unit 

Since this module provides the interface between the user’s 
input from the dialog unit and the model and data components, it is 
imperative that the hardware and software be fast, reliable, and easily 
maintained. Thus the survey participants were accurate in predicting 
the need for modular implementation of this unit. It must be easily 
maintained and modified as data elements and model components 
change. 

The link performed by this unit is very time-critical to game 
play. Player requests for data access should be easily and rapidly 
served by this unit. This can be enhanced by a dedicated processor 
capable of handling the interactive model as well as data. 

Each of the three units of the user interface framework is 
critical in the provision of a complete environment which wargaming 
systems developers must address individually. The components work 
together as a whole to establish a framework for wargame -specific 
decisions. The generic framework established here is only the 
foundation of that task on which much elaboration takes place in actual 
development. 
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V. APPLICATION OF AVAILABLE TECHNOLOGY 



The concepts discussed to this point have indicated several 
proven effective, available modes of technology which the author 
believes, if properly applied, may bring positive results to the military 
wargaming arena. 

As has been stated a number of times in this thesis, each applica- 
tion must be evaluated independently for specific implementations of a 
visual or other effective user interface. However, guided direction 
tempered with good solid research, and strong prototyping and test- 
ing will undoubtedly prove effective in producing improvements. It is 
therefore highly recommended that efforts in this area be actively 
pursued in military wargaming. The following model may provide a 
beginning framework. 

A. AN INTEGRATED FRAMEWORK 

Human beings gather information in many ways. Since human 
information gathering is sensory in nature, it would seem logical to 
support the sensory system as fully as possible. With a visual interface 
alone, even though highly effective, only one channel is open for com- 
munication. With the integration of a voice input/output system, 
another channel is opened. Together, the auditory and the visual 
aspects could be more complete and meaningful. 

This combination also supports the human cognitive processes 
through integrated visual and auditory stimulation. Long-term memory 
requirements are minimized. Visual and auditory information can be 
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processed much more rapidly than textual information if the repre- 
sentations are meaningful. Anxiety levels will be low because of famil- 
iar graphic object representations and the intuitive operations to be 
performed on those objects. Strong feedback and ease of recovery 
from errors will promote user acceptance. Most important, the user’s 
attention is now directed at the wargame instead of trying to figure out 
what to do to effect commands or interpret cryptic output. 

Consider a wargaming system using this integrated technology. If 
a player were to approach a wargaming system which is implemented 
with a relevant, well-developed metaphor for wargaming, recognition 
and interest would immediately develop. If operations were intuitive 
rather than obscure, a player would feel more comfortable in learning 
and using the system. The concepts would allow more recognition 
than memorization, thus lending additional simplicity for all 
concerned. 

The visual aspects alone in an application such as wargaming have 
tremendous potential. Military maps and symbology are largely stan- 
dardized within service branches. The “grabbing" and “dragging" of 
icons and symbols in the Macintosh system are certainly useful con- 
cepts in effecting unit movements and route selection. If extended to 
voice input/output operations such as those in the Dataland system 
(Bolt. 1984), a player could simply point and say “move that there." 
There is no need for fill-in templates or complex commands contain- 
ing long sequences of numbers. 
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A workstation with enhanced capabilities and high performance is 
necessary for fast, high quality graphics and data processing. This may 
be accomplished with a sophisticated system such as the SUN or the 
APOLLO, but a less expensive alternative might be use of a low-cost 
microcomputer such as the Macintosh. 

Regardless of the system chosen, it is suggested that, rather than 
support numerous screens per station, use one high-capability 
screen/terminal. With windowing and complex graphic capabilities, 
one screen can provide one central information control unit. 

1. Implementing the Elements of a Visual Wargame 

Interface 

The variations of visual wargaming interface elements have 
numerous possibilities within the contexts of actual wargaming sys- 
tems. It is important to define in general terms how the visual ele- 
ments of a wargaming interface may be characterized. It is also 
important to note that if properly developed, these elements may be 
further developed into a “standard” group of wargame interface tools, 
such as the elements and functions of the Macintosh Toolbox. The 
fundamental elements to be addressed here are icons, windows, dialog 
boxes, alert boxes and controls, as well as the menu bar and pull down 
menus. 

a. Icons 

Icons are graphic, symbolic representations of files, 
applications, or program functions. They may be moved, activated, 
deactivated, or otherwise manipulated in standard ways. Icons are 
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useful because they contribute greatly to the clarity and attractiveness 
of an application. 

When used as a part of the Apple Desktop, icons gener- 
ally have associated titles listed in text just below the icon. When used 
in an application, titles may or may not be used depending on the pur- 
pose of the icon and the intuitiveness of that purpose. 

Each icon or type of icon has a distinctive appearance for 

rapid recognition by the user. Apple recommends that, wherever an 

\ 

explanation or label is needed in an application, one should consider 
using an icon (Apple Computer, 1986, p. 38). 

As previously stated, icons are graphic representations of 
files, applications, or program functions. Wargaming is an ideal area in 
which to use icons because, in many cases, well -developed military 
symbology already exists. Although not usually standardized across 
military branches, the accepted and understood symbologies are read- 
ily adaptable to the visual interface. 

The JTLS wargame already utilizes standard Army ground 
combat symbology to display unit position on the geographic display. 
BGTT uses the Navy standard NTDS symbology for the same purpose. 
This is an obvious use of the available symbology, but the use of icons in 
wargames should be extended far beyond this traditional method. 

The potential for icon utilization begins with a very sim- 
ple but effective foundation. For example, in JTLS, the player of the 
command terminal has an initial choice of several fundamental types of 
orders. These orders are categorized into operational groups of 
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ground combat, air combat, intelligence, logistics, and so on. Rather 
than issuing a complex typed command stating that the player wants a 
certain amount of fuel transported to a certain unit, then having to go 
through sequential menus and entry of parameters in the necessary 
templates, the visual solution might offer a far superior alternative. 

The visual implementation should allow the player to 
“click” the logistics symbol (in this case, maybe a transport truck) to 
designate that function. That function should respond by offering the 
further selections of fuel, men, food, equipment, or ammunitions. 
These items also lend themselves to easily recognizable graphic 
representation as icons. Also note though that each icon can be 
labelled if so desired or necessary. This provides quick, clear, and 
precise recognition of the choices. 

If the player were to follow the order through to send 
fuel to a unit, he would select the fuel icon, at which time a dialog box 
would prompt him for the amount of fuel and the desired delivery 
time. The fuel load could be represented on a bar scale with a sliding 
indicator and the time could be designated with a clock whose hands 
could also be moved by a mouse action. After the selection, the player 
could “drag” the fuel load icon produced by his actions to the unit or 
units of his choice on the geographic display in a nearby window. 

The possibilities for implementation of icons in 
wargames are almost endless. But more importantly, they can be 
implemented very effectively. The symbols should be easily recogniz- 
able objects, with labels if desired or necessary. They should be items 
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which are common and clear to the user of the system. The user 
should be able to relate to the meaning and intent of the well designed 
icon. See Figure 5. 

b. Windows 

A window is the “frame" through which a user views and 
accesses a document. Depending on the type and size of a document, 
all or part of it may be viewed in the window at any given time. A 
number of windows may be on the screen, displaying the document in 
use as well as other open documents and any associated information. 
Since a particular window represents a document, it is recommended 
that actual document contents not be spread to multiple windows. To 
prevent such ambiguity, split or partitioned windows are used. 

The standard document window contains certain charac- 
teristics used for control or informational purposes. These character- 
istics include a close box, a title bar, a zoom window box, and a scroll 
bar which includes a scroll arrow and a scroll box. 

The functions of these items are fairly intuitive in that a 
zoom box allows one to zoom in and out on the window contents. The 
close box allows the option of closing a document by clicking the 
mouse while the cursor is within the designated area. 

The scroll box allows a document to be scanned in a cho- 
sen direction, whether it be vertical or horizontal. The scroll box acts 
much like an elevator in a shaft. The relative position of the box 
within the shaft shows the user his relative position within the 
document. 
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Figure 5 

Icons 



Windows may exist on different planes. This allows 
applications to have more than one window open at once. Windows 
may overlap each other. One window is “active" while the others 
remain inactive. The “active" window refers to the window currently 
being used. To bring a window to active status so that its contents may 
be manipulated, the user must select it by merely clicking anywhere 
within the window itself. This brings the selected window to the front 
of the others and places it in plain view. The user is therefore capable 
of moving around between windows just as he would with sheets of 
paper. 

Windows have additional versatility. They can be resized, 
and moved to satisfy the user’s changing needs. Windows are capable 
of displaying text, graphics, or a combination of the two. See Figure 6. 

As mentioned above, the user may need to move icons 
within or between windows. Windows provide the user with relevant 
information within logical “frames" of reference. Windows may be 
effectively utilized in a wargame environment to provide the player 
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Figure 6 

Wargame Database Window With Attributes 

with the necessary information as well as a means of manipulation of 
that information. 

The geographic display, which is of primary importance 
in a wargame interface of any type, is an ideal candidate for display in a 
window. The geographic display must be capable of displaying con- 
cise, current information about unit status, action, and interaction. 

The geographic display in current implementations has a 
tendency to become cluttered and difficult to interpret because of the 
requirement for a high level of detail. For that reason, wargames such 
as JTLS and BGTT are capable of decluttering the separate graphics 
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screen by selection of specific items to be displayed and by changing 
the scale of the display. 

The geographic display should occupy a window on the 
user’s primary screen. The window should be capable of movement, 
opening and closing, resizing, and handling different levels of planes, 
just as in any good window implementation. The distinction between 
the traditional implementation and the visual implementation though 
should lie in the degree of user control over the window. See Figure 7. 

The geographic window should be available to the user at 
the “click” of a mouse or any other similarly quick device. The user 
should not only be able to observe the results of his typed commands 
as in other systems, but rather the user should be able to directly 
manipulate objects on the display. Design should allow effective 
movement of objects within and in between windows providing the 
user with more intuitive tools. This is a means to increased speed and 
understanding for the user. For instance, to call a unit in to the arena, 
just “drag” the appropriate symbol from one window to the active 
geographic display. 

With a drop-down menu bar selection, any requested 
status information, database query, or geographical display can be 
immediately available. See Figure 8. Windowing will allow simultane- 
ous viewing and manipulation of several vital screens. The geographic 
display window should allow immediate unit information retrieval for 
items such as current activity, pending orders, strength, losses, com- 
munication paths, resources available, and so on. 
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Windows in a wargame should be flexible but with enough 
structure to avoid ambiguity. The user should be able to call upon and 
graphically manipulate as much information as possible without fre- 
quent switches between the keyboard and the graphics input device. 
This is not entirely avoidable, but in other systems it is not uncommon 
to control the graphic display with cumbersome typing of commands. 
In the visual interface, for instance, to zoom in or out of the geo- 
graphic window, a click in the appropriate “zoom box” will effortlessly 
step the user to the next level of detail. 

Another possible use of windows in the wargame is to 
provide “information planes” whereby the user may select different 
levels of windows through icons, or whatever means, to provide dif- 
fering resolutions of information for the player. For instance, if the 
player is accessing the game data or a player report, a “double click” 
on the window should provide the information in greater detail. A 
“single click” on the window should provide an abbreviated, more 
general view of the information. 

c. Dialog Boxes, Alert Boxes, and Controls 

In addition to standard windows, there are other kinds of 
windows. These are dialog boxes, alert boxes, and controls. These are 
not windows in the strict sense but rather auxiliary types of windows 
which provide specific functions. 

Dialogs allow the system to prompt the user for addi- 
tional information before a command is executed. Dialog boxes are 
either modal or modeless. A modal dialog box requires that the user 
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dismiss the box by performing a specific action or acknowledgement 
before doing anything else. A modeless dialog box allows the user to 
perform other operations without dismissing the box. 

Dialog boxes in the wargame interface will provide a clear 
method of communication with the user. For instance, if the system is 
in need of parameters or information which the user for some reason 
has not specified, the dialog box will appear to inform and prompt the 
user for the appropriate items. An example of this may be in the 
logistics example used previously. The user indicated that fuel was 
required, but the wargame needs to know the quantity and delivery 
time. A dialog box could tell the user that the information is needed, 
specify the parameter range, and wait for the response. 

It is important in dialog boxes that the user maintain 
control of the system such that the user is not forced to input the 
parameters. The dialog box usually will allow a “cancel" function along 
with appropriate warnings and statements of consequence to allow the 
user some degree of flexibility. 

Alerts notify the user in the event of an unusual situation, 
such as an error condition. Since users are error prone, alert boxes 
allow the system to inform them that a mistake has occurred. The 
significance of the mistake and guidance for recovery are usually 
included in the text. See Figure 9. 

Alerts in a wargame can be used to warn the players of 
threats within the game itself as well as to warn the players of unusual 
situations and system error conditions. Guidance should be provided 
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Figure 9 

Typical Alert Box 

to inform the user of appropriate actions and/or recovery procedures 
so that wargame play can be continued with as little difficulty as 
possible. 

Controls are graphic objects which can be manipulated 
with the mouse to perform instant actions, either visually or audibly. 
Controls can have four basic varieties: buttons, check boxes, radio 
buttons, and dials. 

Buttons are small objects, found usually within a window, 
labeled with text or an icon. A button performs an instantaneous or 
continuous action described by associated text. Check boxes act like 
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toggle switches to turn functions on or off. Radio buttons occur In 
groups in which only one radio button can be active at the time. Dials 
display a value or magnitude which is alterable by the user (Apple 
Computer, 1983, pp. 32- 33). 

Controls are graphic objects which can be used to 
increase and enhance the manipulation characteristics of the 
wargame. Familiar objects may be graphically depicted to guide the 
user to the choices available. For instance, to turn on radar, a player 
may “click” on a graphically depicted toggle switch or button, or to 
increase the sensitivity of some equipment the player may turn a dial. 
There are numerous possibilities for implementation of control ele- 
ments in wargame systems. See Figure 10. 

d. Menu Bar and Pull-Down Menus 

The menu bar is displayed at the top of the screen. It 
contains logically grouped titles of the pull-down menus which are 
available to the user for expressing commands. Pull-down menus may 
consist of text or graphic entries. Each application usually has its own 
menu bar to make program-specific selections available. These selec- 
tions remain constant throughout the application, though all com- 
mands may not be available or operative at all times. Users are always 
able to peruse the available commands while maintaining the informa- 
tion being worked on in the current document on the screen. 

The menu bar and pull-down menus are ideal for imple- 
mentation in war gaming systems. The menu bar provides for cate- 
gories of commands to be actively displayed for selection during game 
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Figure 10 

Different Types of Controls in a Window 

play. The pull-down menus ’ allow the user to select specific com- 
mands from those categories. The benefits in a wargaming system are 
that the user has only to recognize a command to use it. Cryptic 
command structures do not have to be memorized or frequently refer- 
enced. See Figure 11. 

The menu bar should contain standard commands and 
functions for all players, but depending on the command needs of the 
player station, the menus and menu bars will vary accordingly. A point 
of caution should be noted here. With the large number of commands 
usually necessary in wargaming systems, care should be taken to avoid 
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Menu Bar With a Pull-Down Menu 

confusing and numerous menus. Careful design and integration will 
avoid associated problems. 

B. HARDWARE/SOFTWARE REQUIREMENTS 

The hardware is composed of a number of high-speed worksta- 
tions, each consisting of a large -surface, high-quality, high-resolution 
graphics monitor and a pointing device or touch screen with a key- 
board for manual input. The workstation ideally has extensive local 
graphic processing and database storage capabilities. 

Hardware and software requirements will vary widely depending 
on the extent and method of implementation. Workstations are 
becoming more and more popular due to their strength and flexibility. 
They are also providing more value per dollar as hardware prices 
decline. As mentioned above, the SUN and APOLLO are examples of 
such systems, but advanced microcomputers such as the Macintosh 
might easily serve as low-cost alternatives, especially in the develop- 
ment stages. 
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C. IMPLEMENTATION: A SESSION IN JTLS 



This portion of the thesis will address two scenarios: 1) a JTLS 

wargamer stepping through a task in the current interface, and 2) a 
JTLS player stepping through the same task in a hypothetical visual 
interface. Figure 12 illustrates a comparison of the man-machine 
interactions for the two scenarios. 

1. The Current JTLS Interface Scenario 

The current JTLS interface, as described previously, is menu- 
based. A player involved in a JTLS wargame is faced with sending 
numerous commands under tight time constraints. The scenario to be 
addressed here is for the ground terminal player to create an attack 
mission. This involves a common operation for the ground player and 
resembles tasks which other players must perform on a regular basis. 

At this point in the game, the player has already been playing 
actively, building and sending directives to perform various actions. It 
is common in the current version of JTLS for the player to reuse 
directives created previously by modifying them to reflect newly 
desired parameters as the game progresses. This is done because 
modification of previously built orders, while still tedious, takes con- 
siderably less time than developing new ones. However, in this case, 
the player is creating a new attack directive. 

Assuming that this player is new to JTLS, he will first attempt 
to refresh his memory with a menu option which might allow him to 
inform himself how to perform this task. His first action will be to 
type “?" in an attempt to display the top-level directives (assuming he 
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Figure 12 

Comparison of typical Man-Machine Interactions 
For the Two JTLS Scenarios 



is currently at the top level of the menu structure). If the player is at 
the top level, he will see a screen display of menu options, three of 
which will allow the player to move into a manipulation level. He finds 
the command desired at this time, the “Create" directive. 

Again, as a novice, the player may have forgotten the next 
syntactical element to be entered, therefore, he will type “CR ?" to 
display his options at the manipulation level. “Attack" appears in the 
list as option number three out of seventeen available choices now on 
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the screen. The player then recognizes the command and enters “CR 
AT,” which is the abbreviated form of “CREATE ATTACK.” 

After this entry, a template for the attack directive appears 
on the screen. This particular template has nine parameters which 
must be completed. In addition, the completion of another entirely 
different directive sequence and template is necessary to provide the 
ground route for the attacking forces, the name of which is provided 
as the ninth parameter of this first template. 

During template completion, feedback is minimal. The first 
parameter in the attack template is called “REFERENCE.” This is 
actually a name by which the player may reference this particular 
directive after completion, e.g., for the directive to be sent to the 
game for execution. The player may insert any name which he 
considers appropriate here, but when the player attempts to enter the 
parameter for item number three, “UNIT,” the player must be able to 
specify an accurate unit name which is active in the current game 
database. Otherwise, the game will respond with “There are no 
GROUND units whose name begins with 82A.” Unfortunately, the 
player at this point must escape his current activity and review the 
database for an accurate name. This is time consuming and trouble- 
some, especially for the novice, but it happens to all types of players at 
one time or another. 

After the player finds an appropriate entry for the name 
parameter, he must reenter the template (if he knows how) and con- 
tinue along the same path until the directive and the ground route are 
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complete. The player then must return to the top level and. when 
ready, recall the directive for the “SEND” operation to actually enter 
this directive into game play. 

This is an abbreviated hypothetical case used as an example 
only. A number of sample command sequences may be followed in the 
JTLS Player Guide (CPS. 1984) 

2. A Visual JTLS Interface Scenario 

In this scenario, the JTLS player sees a much different por- 
trayal of the system. The player screen consists of a menu bar across 
the top of the screen. The menu bar always contains a pull-down 
menu for the currently available wargame “DIRECTIVES” as well as a 
“HELP” pull-down menu, a “GENERAL PURPOSE” or “UTILITY" pull- 
down menu, and a “WINDOWS” pull-down menu. The menu bar may 
vary in content or accessibility with the current game modes or player 
choices. 

The “GENERAL PURPOSE" or “UTILITY" menu provides 
functions which are useful during any part of game play, such as 
“CANCEL” to quickly escape the current series of player actions. 
Upon selection, the cancel option presents a dialog box asking, “Will 
you resume this operation later? If so, it will be saved, if not it will be 
destroyed.” At this point, the player may point and click to either the 
“SAVE” or “CANCEL” options according to his situation. 

The “WINDOWS” pull-down menu allows the user access to 
various informational displays, such as the geographic display or the 
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database query window, which is capable of displaying textual and 
graphic database information. 

Additional items appearing on the screen may be a palette of 
icons used for common operations which are modal in nature, such as 
the designation of ground units, or weapon load creation, or message 
sending. For instance, a telephone icon is resident in the palette at all 
times, just as a communications device would be at the commander’s 
disposal. The player uses his mouse to click on the telephone icon to 
activate communication. Immediately, a dialog box appears requesting 
the sendee’s name or identification. The available choices within the 
current game appear in a scroll region to be readily accessible to the 
caller. The caller may scroll until he finds the correct entry, at which 
time he may double click to select that party, or if multiple parties are 
desired, he may press the shift key on the keyboard and click any 
number of parties, each of which is highlighted as he clicks on the 
entry. When finished he clicks on the text input region and types the 
message. He may at any time click either a “SEND” box or a 
“CANCEL" box as appropriate. 

To accomplish game directives as in the current JTLS inter- 
face example above, the player initiates action by placing the cursor on 
the menu bar above the “DIRECTIVES" category. As the player 
presses the button on the mouse, a pull-down menu containing the 
currently available game directives is displayed. The player moves the 
cursor over the “CREATE" directive and releases the mouse button. 
Immediately the menu bar reflects a change by displaying a new menu 
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bar selection, “ACTIONS.” This indicates to the player that he now 
has the option of continuing his directive by accessing this pull-down 
menu as well. 

Notice one thing. The user still may change his mind. If he 
returns to the “DIRECTIVE” pull-down menu, he may cancel the pre- 
vious selection by making another selection. This interface is event- 
driven, not hierarchical as in the other JTLS interface. The user now 
decides where he wants to be. If he chooses not to cancel, and con- 
tinues in his original path, he may select “ATTACK” from the 
“ACTIONS” pull-down menu. 

A dialog box appears immediately. This dialog box provides a 
unique reference name which may be changed if desired. A scroll box 
containing candidate unit names appears to provide data for item 
number three. The user scrolls to the appropriate unit, then clicks on 
it. A digital clock icon appears to provide for the execution time in- 
put. The user clicks on up and down arrows to indicate the appropri- 
ate time, then clicks outside the clock icon to indicate approval. 
Scroll boxes are available for the “ATTACK WITH,” “PROTECT WITH,” 
and “SCREEN WITH” parameters. These may be ignored if no entry is 
desired. 

The final parameter to be entered is the “ROUTE" which 
provides a path for the unit to take to a destination. The user clicks 
on “ROUTE” to indicate that he is ready to fill this parameter. The 
geotactical display window appears with the specified unit(s) appear- 
ing in their current positions on the map. The user then points to the 
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unit(s), presses the mouse button, and moves the cursor along the 
desired route to the destination. Notice no coordinates were looked 
up, written down, or repeated by another person as usually happens in 
the game. 

The user then selects “SAVE,” “SEND,” or “CANCEL” and 
the directive is accomplished with a minimum of effort. The support 
required for the player is self contained in one workstation. Several 
other people are not now needed to chart routes, research unit or tar- 
get names, or provide game instructions. 

This interface provides a continuously available help facility, 
and, at practically any point, will allow the user flexibility in the way he 
wants to enter commands and access data or reports. When con- 
trasted to the current JTLS interface, it seems that much time and 
effort could be saved in this type of implementation. The most impor- 
tant aspect, though, is the usability of such an interface. The user will 
feel much more comfortable pointing to familiar objects than typing 
complex syntax. The user will be more comfortable with a system 
which he feels he controls and which is most forgiving of his mistakes. 
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VI. CONCLUSION: A NEW USER ENVIRONMENT IN WARGAMING 



In a foreword to Richard Bolt’s book, Nicholas Negroponte of MIT 
(1984) makes a very strong case for Improvement of the human inter- 
face. This excerpt is included here because it strongly reiterates the 
ideals of this thesis. “The human interface with computers is the 
physical, sensory, and intellectual space that lies between computers 
and ourselves. Like any place this space can be unfamiliar, cold, and 
unwelcoming. But it can also be like some other places, those we 
know and love, those that are familiar, comfortable, warm, and, most 
importantly, personal.” (Bolt, 1984, foreword) 

User benefits have been emphasized throughout this thesis. It 
serves no practical purpose to list them all again, but it does serve a 
practical purpose to recognize the fact that the benefits from such 
modification of user interface software will be significant for all users. 
The novice and the expert will both experience large gains in 
productivity. The long-term development of the visual interface into 
an even stronger tool holds virtually unlimited potential. It is limited 
only by the imagination because eventually the technology will be there 
to support it. 

The Department of Defense supports vast research and develop- 
ment in many important fields. The area of the user-computer inter- 
face affects all of us. The potential benefits of friendly, easily under- 
stood interfaces are innumerable. 
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Only through dedication to the ideal of making computers work 
for us will we ever have full command over the available resources. To 
ignore readily implementable systems which will establish a milestone 
foundation for the advancement of the military and society in general 
seems wasteful and unproductive. Implementation of such interfaces 
will open new avenues of communication and creativity which can lead 
to strong positive strategic growth potential. 

The technology discussed in this thesis is readily available for 
application to the wargaming environment. Implementation costs may 
be high for full-scale implementation, but long-term benefits should be 
immense to the Department of Defense. If managed properly, with 
small-scale development and prototyping followed by thorough test- 
ing, costs can be cut drastically. It is very inexpensive and simple to 
develop a prototype on a Macintosh system which will simulate the 
workings of a full-scale implementation. 

It is expected that certain elements of the visual interface will 
productively lend themselves to the improvement of the visual 
wargame interface. These elements include: 

1 ) Extensive use of metaphors, icons, and familiar graphic symbol- 
ogy to promote rapid learning and transfer of knowledge and 
understanding. 

2) Use of windowing for centralized attention to a single screen for 
the direct manipulation and control of the interface by the user. 

3) Use of dialog and alert boxes, and controls for ease and clarity of 
communication between the user and the computer. 

4) Command entry by menu bar and pull-down menus for availabil- 
ity and recognition versus memorization of commands. 
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Further research in the area of specific application is necessary. 
While the JTLS and BGTT system interfaces are good candidates for 
visual interface implementation, it will be necessary in follow-on work 
to develop prototypes which will effectively implement visual princi- 
ples as well as model the wargame systems and users. Specific rec- 
ommendations for the development and implementation of advanced 
interfaces include: 

1) Thorough requirements analysis of the wargame user interface 
from a user’s perspective. 

2) Research of graphic workstation technology for capacity, capa- 
bility, and interface evaluation. 

3) Further research of available visual interface principles, includ- 
ing a development plan for application specific transfer of 
principles. 

4) Design and prototyping of interfaces based on conclusions of 
research. 

5) Testing and evaluation of prototypes, coupled with further 
refinement based on results. 

6) Evaluation of results to determine common elements which may 
be applicable to the development of a ‘Toolbox” type of interface 
tool for use with different wargame systems. 

It would be most interesting and productive to compare the 
results of such research for common factors. If commonality is found, 
further research may prove useful in the development of a generic 
toolbox system for implementation of these and other wargame sys- 
tems. If this were possible, the costs could be spread across many 
applications, while benefits of standardization of a very good interface 
could multiply with use. 



88 



Wargaming is becoming an invaluable tool in strategic force plan- 
ning and analysis. It only seems prudent to bring such a valuable tool 
to the user in a highly refined state. Based on the information avail- 
able, the visual interface— and in the near future, voice technology— 
appear to be a most practical direction for substantial improvement in 
wargaming systems. 
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